With the increased use of wireless and non-wireless communications networks, such as the Internet, cellular communications systems and other communication systems, information security is becoming increasingly important. With e-mails or other communications, the forging of e-mail messages can result in enormous legal and financial losses. Information security systems, such as public key-based security systems, employ encryption and digital signing techniques as known in the art to facilitate information security among software applications, or other entities. Using digital signature algorithms, an e-mail message may be signed by a sender. Typically as part of a message, a transport header includes fields indicating from whom the message came, to whom the message is intended, and further routing information. For example, a domain name subject (i.e., the data in the “from” field) may be interpreted as the initiator of a message. A public key infrastructure can automatically verify a digital signature that is attached as part of the message body.
A problem arises when an attacker, such as an attacker that is part of a trusted system, such as a system using certificates and cryptographic keys, changes a transport header indicating that a message is coming from a different source. For example, an insider attack can occur where an attacker and a recipient have exchanged certificates. The attacker's system can construct a fake signed body by modifying a transport header so that a recipient thinks the message came from a party listed in the “from” field in the transport header since there may be no cryptographic binding between the transport header and the message body that has been encrypted and/or digitally signed.
Internet RFC 2632 entitled “S/MIME Version 3 Certificate Handling” proposes an option where certificates use fields such as a certificate subject field and a subject alternate name field so that a subject can use an alias to index an e-mail address. For example, if there is a specific e-mail address, the receiving agent checks to see if the e-mail address in the certificate from the secured body in either the subject field or alternate name field matches the sender's e-mail address in the transport header. If the e-mail addresses do not match, a message may be displayed indicating a potential security problem.
A problem with such a solution occurs when the header e-mail address is close to the cryptographic body address but does not exactly match. For example, if a sender uses two e-mail addresses such as Joe Public @ e-mail and Joseph Public @ e-mail, these two e-mail addresses may be associated with the same person. An administrator may issue a certificate with a subject field that does not match the e-mail address identically. Accordingly, the subject field in the certificate may differ slightly from the e-mail address in the transport header. The proposed Internet draft suggests that a user can accept the message as authentic each time it is validated since he can override the rejection at each such occasion where the mismatch is detected forcing an unnecessary burden on the user. In a popular implementation of RFC 2632, the user is given the option of turning off the mismatch warning. However, overriding this warning requires that all instances on all received e-mails be overridden so that the system may not detect an attack if it is selected to override the detected discrepancy.
An alternative solution would be to issue a new certificate replacing or appending the correct e-mail address. However, issuing new certificates can be onerous particularly where hundreds of thousands of users are members of a trusted community. In addition, users may have use of a plurality of email addresses so that a certificate may need to be reissued, each time a user obtains a new email address for themselves.
In addition, another problem can arise even after a message is successfully validated and displayed from a “friendly name” such as “Joe” corresponding to the email address in the transport header. There is a possibility that the friendly name can be mapped to appear to come from another source by changing an e-mail address associated with, for example, the name in an address book program. For example, the address book program may have mapped Joe Public @ email to the friendly name Joe, to provide an alias mapping of “Joe” to the email address. If Joe were to be able to alter this mapping to the friendly name (i.e., alias) Vice President, then the recipient of such a message sent and signed by Joe, would be lead to believe that the message actually came from Vice President.
Accordingly, there exists a need for a method and apparatus for providing information security to thwart forging of communicated information.